【レポート】バンダイナムコスタジオ様事例セッション「クラウドを使ったゲーム開発の効率化（ゲーム開発パイプラインのクラウド化）」 #AWSSummit

こんにちは、コンサルティング部の後藤です。

皆さん、AWS Summit Online 2020楽しんでいますか？今年のAWS Summitはオンラインで開催されており、150を超えるオンデマンドセッションをいつでもどこでも9/30まで視聴することが出来ます。

今回はその中からバンダイナムコスタジオ様で開発中のタイトル「BLUE PROTOCOL」でビルドパイプラインをクラウド化した事例セッションを見てきましたので、セッションレポートを投稿させて頂きます。

クラウドを使ったゲーム開発の効率化（ゲーム開発パイプラインのクラウド化）

セッション概要

ゲーム品質の高度化に伴う開発期間の長期化やゲームエンジンでのビルド時間増加の現状に、バンダイナムコスタジオのブループロトコルプロジェクトにおけるゲーム開発のビルド、ライトのベイクなどのクラウド化による開発効率化とスピード向上、コスト削減の実現と今後の展望をご説明します。

スピーカー

株式会社バンダイナムコスタジオ 技術スタジオ技術スタジオ付エグゼクティブテクニカルディレクタｰ 大井 隆義 氏
株式会社バンダイナムコスタジオ 総務 IT サｰビス部 吉田 卓哉 氏

アジェンダ

• BLUE PROTOCOLとは？
• ゲーム開発でのビルドパイプライン解説
• BLUE PROTOCOLのビルドパイプラインをクラウド化した話
• クラウド化した結果や成果、わかった事
• 細かすぎて伝わらない初心者のハマりどころ

BLUE PROTOCOLとは？

現在、バンダイナムコスタジオ様で開発中のタイトルの一つで、劇場アニメを思わせるようなグラフィックで描かれるオンラインアクションRPGで、今年の4月にはクローズドβテストも実施されています。
プラットフォームはWindows、ゲームエンジンにはUnreal Engine4を使用しています。

ゲーム開発でのビルドパイプライン解説

今回、クラウドに移すパイプラインは以下のような構成になっています。

バージョン管理にはPerforceを採用、エンジンにはUnreal Engine4を採用しています。

Build部分はパッケージ作成までの工程になっており、Perforceからソースコードやアセットを取得してCompile、Cookを行い最後にパッケージ化していきます。
Cookとは、アセットをWindowsやコンシューマなど、プラットフォームに適したデータに変換する工程のことです。

Bake/Precompute部分はライティングや影といった背景情報やNPCの挙動といった事前に処理が必要なデータとなっている。

BuildやBake/Precomputeは対応するプラットフォームやブランチ等、条件が増える毎に増えていきます。

BLUE PROTOCOLのビルドパイプラインをクラウド化した話

クラウド化の前に、ゲーム開発環境をクラウド化する際の課題を整理します。
ゲーム開発は社内のローカル環境が主流となっており、クラウド化にシフトしにくい理由は以下の3つあります。

• 社内LAN前提で構築されたゲーム開発環境
  ユーザ認証基盤、ファイルサーバ、VCS、インフラ、セキュリティといったものは社内LAN前提で構築されているため、一部だけを切り出してクラウド化するのが困難。

• スピード/トラフィック
  大量かつ大容量のアセットデータ(1つのpsdファイルが1GBを超える)を取り扱ったり、高速ビルドを行うためいつでも150コア並列分散ビルドできるを環境を用意したり、また描画性能や操作レスポンスの確認のため4k、60fpsが必要。

• 契約関連(NDA,EULA)
  ゲームエンジン、ミドルウェア等の開発ツール、また1stパーティ製SDKはクラウドでの利用が前提されていないものや、そもそもクラウドで利用して良いのかの確認が必要となる。

以上の理由から、全て解決してクラウド化するのは非現実なため、クラウド化可能な部分として今回はビルドパイプラインのクラウド化を進めた。

従来のビルドパイプライン構成

社内環境でJenkinsを積んだビルド環境が複数動いていて、Perforceから最新のデータを取得してビルドし、その結果をストレージに書き込んでいる。
ビルド環境やPerforce、ストレージは社内環境からのみアクセスを許可しており、社外環境からはアクセス出来ないようになっている。

Jenkinsでビルドでは「Incredibuild」を利用して最大150コアを使った並列分散ビルドを実現し、ビルドを高速化している。
現在300エージェントほど稼働しており、社内の開発者PCやビルドファームの余剰CPUを使用している。

最大150コアの並列分散ビルドを行うことで、ビルドスピードには不満が無いか運用面で以下のような課題や悩みがある。

• ビルドマシンの調達に時間がかかる
  ハイスペックなマシンが必要となり、時間がかかる。

• ビルドマシンのセットアップが大変
  調達後、各種ツールの導入やJenkinsのジョブ設定を要する。

• ビルドマシンの運用が大変
  セットアップ後は設置スペースや停電、故障等障害時の対応が必要。

• 増えるJenkins
  Jenkinsがどんどん増え、運用期間が長くなればなるほど故障時のトラブル対応のリスクが大きくなる。

クラウド化したビルドパイプライン構成

AWSにJenkins、PerforceProxy、ビルドマシンを構築しています。
PerforceProxyは社内環境にあるPerforceから最新データを定期的に取得している。

Jenkins、PerforceProxyは24時間稼働していて、ビルドインスタンスは必要になった時に起動している。

各種インスタンスのスペックは以下の通りです。
- Jenkins : t2.micro
- PerforceProxy : t2.small
- ビルドインスタンス(Build) : c5.24xlarge (96コア)
- ビルドインスタンス(Bake) : d4dn.16xlarge(64コア with GPU)

ビルドインスタンスのインスタンス選定理由は一番CPUコアが多かったため。
ほぼ全てのCPUを100%使用出来ている。

クラウド化したビルドパイプラインではJenkinsを1台で運用してビルドインスタンスはビルド実行中以外停止してコスト削減を行い、複数のJenkins管理から脱却することで運用コストの削減を行った。

1台のJenkinsで複数のビルドインスタンスを使ったビルド方法

Jenkins以外にAWSサービスとしてAWS CLIとAWS Systems Managerを活用した。

まず、JenkinsでAWS CLIを使用してビルドインスタンスを起動し、SSMでビルドを実行している。
ssmのsend-commandを実行する時のポイントは「executionTimeout」を設定すること。
executionTimeoutはデフォルトでは1時間で設定されており、ビルド実行時間が1時間を超えるとタイムアウト処理されてしまうため、この設定が必要です。

次に、ビルド実行時に返答されるコマンドIDを使用してビルド状況を確認、ビルド状況が「Inprogress」であれば再度ステータスを確認し、ビルドが完了するまで続けます。

次に、ビルド成功or失敗の判定を行う。get-command-invocationのqueryオプションでStandardErrorContentを与えてあげることで、標準エラー出力結果が返答されます。このエラー出力に何かしら返答があればJenkinsは失敗と判断しています。
ビルド結果は問わず、ビルド完了後はインスタンスを停止しています。

以上がJenkinsでビルドを行う際の流れになります。

クラウド化したビルドパイプラインの処理

全体のビルド処理は以下のような流れになっています。

1. JenkinsからPerforceProxyを経由して最新のリビジョン番号を問い合わせる。
2. Jenkinsからビルドインスタンスを立ち上げ、リビジョン番号を指定してビルドを実行。
3. ビルドインスタンスはリビジョン番号を元にPerforceProxyから取得。
4. リビジョン取得後、ビルドインスタンスが並列でビルド処理を実行。
5. ビルド完了後、成果物をS3にアップロード。
6. Jenkinsにてビルド結果を受け取り、ビルドインスタンスを停止。
7. 必要に応じてS3にある成果物を各拠点から取得。
   この時、個別にS3から成果物を取得するとコストがかかってしまうため、社内ストレージにも保存している。 　

クラウド化した結果、成果、分かった事。

Compile、Cook、Packagingをローカル環境、IncrediBuildを使用した従来の方法、クラウド化の3つの方法でビルド処理を検証。

• Complile
  従来のIncrediBuildを使用した方法が圧倒して高速だった。これはIncrediBuildを使用した従来の方法では150コアのCPUを活用できるが、クラウド化のc5.24xlargeでは96コアであったため。しかし、クラウド化でも十分許容できる時間に収めることが出来ている。

• Cook
  UnrealEngine4を使用しており、キャッシュを利用しているためあまり参考にはならなかった。

• Packaging
  Packagingの処理ではIncrediBuildが動作しないため、コア数を多く使えるクラウド化が圧倒した。

これらの結果から、クラウド化でも従来と遜色ない速度が出ており、クラウド化しても問題ないと判断。

Bake Ligitngに関しても検証されており、こちらはUnreal Swarmという並列処理の方法とクラウド(g4dn.16xlarge)で処理時間を比較。

こちらは時間としてはあまり差はありませんが、1つのマップでこれ程の時間を要するため、大量のマップを処理するためには多くのサーバが必要となりますが、インスタンスを調達できるクラウド化であれば容易に出来ると判断した。

今回クラウド化した結果、1か月のランニングコストは $1655.85
この結果はビルドの並列処理数や実行時間等でも変わってくる。

クラウド化までのスケジュール感

クラウド化を進めるにあたり、検証から実際に導入までのスケジュール感は以下の通り。

• 2019年
  • 11月 : 検証スタート
  • 12月 : AWS環境構築、Jenkins無しでPerforceProxy経由でビルド速度計測
• 2020年
  • 1月 : ビルドパイプライン構成を決定
  • 2月 : Jenkinsジョブの作りこみ、ビルドスクリプトアップデート
  • 3月 : 進捗無し（COVID-19関連
  • 4月 : 進捗無し（COVID-19関連
  • 5月 : CloudFormationによるBLUE PROTOCOL用AWS環境構築
  • 6月 : プロジェクトでの実運用開始

大体約半年ほどかかってはいるが、主業務とは別に片手間で進めていたこともあり時間を要した。

細かすぎて伝わらないAWSハマりどころ

• AWSアカウントの作成をどうしよう？
  社内で契約があるのか確認を行った。

• クラウドビルドパイプラインの構成で悩む
  AWSサービスは選択肢が多いのでソリューションアーキテクトに相談して全て解決

• WindowsインスタンスでRDPできない
  会社のファイアウォールで Deny されていた

• インスタンス作成から数か月後、突然RDP出来なくなった
  Windowsパスワード更新期限が過ぎていた。無期限して解決した。

• 従量課金のため金額の試算が難しい
  1回のビルド実行時間、データ量、通信回数で大体試算できた。

• リージョンはどこが良いか

  • 東京リージョン : スピード重視
  • オレゴンリージョン : 安さ重視（東京よりも約1割安く、転送速度が約2倍遅かった
  • バージニアリージョン : 新機能重視（しかし障害件数が多い傾向にある
• ビルド開始後1時間でタイムアウト終了してしまう
  SSMコマンド"executionTimeout"を設定することで解決した。

• 万が一ビルドインスタンスが停止せずに高額課金になることを防ぎたい
  Lambda + CloudWatchで長時間稼働インスタンスを停止している。

• EBSのIOPSは足りているか
  CloudWatchでスループットを確認している。

まとめ

社内LANに閉じた開発環境を一部クラウドに移行することが出来た。ローカル環境で使用していた時とビルド時間も遜色なく、Perforceの取得もPerforceProxyを使用することで解決できた。クラウドのメリットであるインスタンスを容易に増やせる点や物理Jenkins管理からも解放された。

最後に

以上、バンダイナムコスタジオ様の「BLUE PROTOCOL」のビルドパイプラインをクラウド化した事例セッションでした。既存環境をクラウド化するために必要なことは、出来るところからクラウド化を行うことです。このセッションではその進め方が非常に参考になると思います。また個人的にバンダイナムコスタジオ様のBLUE PROTOCOLは非常に楽しみにしているタイトルなので、その開発環境を一部知ることが出来る貴重なセッションでした！